public class Main {
    public static void main(String[] args) {
        // 1. ***** 什么是需求 *****
        // （1）定义：
        //   .用户需求：可以理解为甲方提出的需求， 如果没有甲方，那么就是终端用户使用产品时必须完成的任务。 该需求一般比较简略
        //   .软件需求： 或者叫功能需求， 该需求会详细描述开发人员必须实现的软件功能。 是一个文档（详细描述用户需求是如何实现的）
        // （日常通常使用软件需求来进行开发和测试的）
        // （2）为什么要有需求：
        //      需求就是一个标准
        // （3）测试人员眼里的需求是什么：
        //      需求就是一个一个子需求， 将其拆分
        //
        // （4）如何深入了解需求：
        //      需求评审会议 ， 收入要达到什么标准， 产出小于投入， 软件要做成什么样
        //     如今天评审了这个需求，： 测试人员今天就要测试吗？ 开发人员今天就要开发吗？
        //     不可能做到这样的， 而是看情况， 玩意是 优先级最高的， 通常是拿工作量来说的， 一般过了一段时间才能做这个项目
        //      查阅文档（需求文档， 技术文档， 找产品了解软件功能， 找开发了解软件实现）
        //  经常常用的几个方式：参加需求评审会议， 查阅文档 ，沟通

        // 2. 测试用例 （CASE）
        //  1） 什么是测试用例
        //      测试用例是一组集合， 用来测试功能的一个方法， 测试环境， 测试数据， 预期结果， 操作步骤...
        //
        //        测试环境： leetcode提供给我们一个测试环境（浏览器）
        //        测试数据： 字节输入测试数据 80%
        //        预期结果： 通过率 100%
        //        操作步骤： 写代码， 提交
        //        测试用例： 序号 1，2，3...
        //                  级别: 中等， 或者p0， p1
        //                  标题： 全部通过， 此时展示一个动画效果
        //
        //         本地运行：
        //         来讲解： 登录qq是否能够成功
        //         测试环境 ： windows系统+chrome浏览器+本地 （linux系统+云服务器）
        //         测试数据： 账号，密码
        //         操作步骤： 输入账号， 输入密码， 点击登录
        //         预期结果： 登录成功（看与预期结果是否相同）.
        //  2） 为什么要有测试用例：
        //          测试用例是让几个人写， 一个人就可以写一周
        //      1） 测试用例 可以提高测试人员的测试效率， 可以降低测试人员的工作重复性问题
        //      2） 测试用例是我们简历测试自动化的基础
        //        自动化就是把测试人员双手解放， 让代码代替测试人员执行测试，
        //  3） 练习
        //      巩固一下完成一个用例的小例子
        //      手机打电话
        //      功能相关的测试点：  手机号码的正确性， 黑名单， 不同地区的电话号码 （这些都放在后面讲）
        //      性能相关的测试点：
        //      .
        //      打电话之前
        //              数字， 或者带着其他特殊符， 号码的正确性.
        //      打电话过程中
        //      挂机之后.
        //

        // 3. BUG
        //  什么是 BUG ： 结果 与 需求不匹配
        //  专业定义： 当且仅当规格说明书存在并且正确 程序与规格说明之间不匹配才是错误   （预期结果 ！= 执行结果）
        // 规格说明书 是产品经理写的


        // 4. 软件的声明周期
        //  什么是 生命周期： 可以分为 6 个阶段： 需求分析、计划、设计、编码、测试、运行和维护
        //  需求分析阶段： 分析需求是否合理， 需求是否完整
        //   计划阶段： 谁开发， 谁测试， 开发多久， 测试多久...
        //   编码： 写代码
        //   测试： 测试报告
        //   运行维护： 如果有线上问题， 此时测试人员需要协助开发定位问题+解决问题

        // 5. 开发模型                                            写代码    执行测试用例，提交BUG
        //    1） 瀑布模型 ： start --> 需求分析 --> 计划 --> 设计 --> 编码 --> 测试 --> End
        //                           需求文档      技术文档（涉及哪些接口， 库表，mq，定时任务， UI视觉搞） （UI 视觉稿， 是一个一个的图片， 网页的模型排版）
        //          以上就是 瀑布模型的特点
        //              特点： 是一个 线性的
        //              优点： 每个阶段做什么， 产出什么非常清晰
        //              缺点   风险往往迟至后期的测试阶段才显露， 因此失去及早的纠正机会
        //
        //              适用项目： 小型项目适用于这种模型.

        //     2） 螺旋模型： 如同骡一样， 一圈一圈的， 反复测试反复分析
        //           优点：每个阶段都会进行风险分析， 避免一些线上问题的发生
        //           缺点： 风险分析可能会出现问题，可能会分析错， 需要有 人力和财力的投入
        //           使用项目：使用于 比较大的项目， 风险比较多
        //     3） 开发模型
        //      增量， 迭代
        //     增量和迭代的区别：
        //          增量：
        //          迭代：

        //      敏捷： 属于一种思想，
        //      个体与交互重于过程和工具 ： （个体之间面对面的的沟通， ）
        //      可用的软件重于完备的文档  ： （文档： 开发文档， 需求文档...）
        //      客户协作重于合同谈判： 如 工作之后的 劳动合同
        //      响应变化重于遵循计划：
        //      在每对比对中，后者并非全无价值，但我们更看重前者。： 强调的是前者.
        //      敏捷的重要 开发： scrume
        //               三大角色： product owner（产品经理）、scrum master（项目经理）和 team（研发团队）组成
        //                      team 是由很多人构成的， 这里面的人具备的技能是各种各样的
        //               流程：
        //       软件测试 V 模型：
        //          用户需求（产品经理将用户需求收集形成软件需求）                                 验收测试（让产品或者运营）
        //              需求分析与系统设计（验证需求是否正确， 确定编程语言，确定框架）            系统测试（模块和模块之间没有影响）
        //                  概要设计（项目结构如何设计）                                集成测试（将许多方法集成到一起测试）
        //                      详细设计（每个接口，要涉及到哪些库表...）             单元测试（Java中测试每一个方法，每一个类）
        //                                                      编码（写代码）
        //         V模型的
        //             特点： 左边是开发， 右边是测试
        //             优点：测试被划分成许多类型
        //             缺点： 测试人员介入太晚，发现问题的时机就太晚.
        //
        //        W模型或者叫做双V模型
        //         看图片
        //           特点：开发是一个 V 测试是一个 V
        //           优点：测试人员今早的介入了需求
        //           缺点：测试人员和开发人员一定程度上还是一个穿行的
        //                不能拥抱变化（）， 不能使用与敏捷
        //



        // 基础篇
        // 软件测试的生命周期                    | 执行测试用例
        // 需求分析->测试计划->测试设计、测试开发->测试执行->测试评估 （写一个测试报告）（测试报告就是一个文档）
        //                          |（写测试用例，什么时候开始用例，什么时候结束用例）
        //   测试报告内容
        //      测试人员：
        //      测试时间：
        //      开发人员
        //      开发时间：
        //      测试用例：
        //      bug：
        //      文档：需求文档，技术文档
        //      最好最后写一个测试报告.
        // 如何描述一个bug： 这一块死记硬背
        // 如何定义bug的级别： 优先级处理， 影响严重的先修复， 影响级别：
        //              1.Blocker（崩溃） 阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错
        //                              误，主要功能丧失，基本模块缺失等问题
        //              2.Critical（严重） 系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他
        //                               功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用
        //                               冲突，安全问题、稳定性等。
        //              3.Major（一般）  功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
        //              4.Minor（次要）  界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。
        //         如果发现崩溃级别级别的BUG， 那么此时就需要停止测试，测试打回， 打回给开发，接下来开发就需要去修复.
        // bug的生命周期 ：
        //  每个公司、每一个工具对bug生命周期的定义都是不一致的
        //  测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态
        //   BUG状态转换图
        //    New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
        //● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
        //● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
        //● Rejected：如果认为不是Bug，则拒绝修改。
        //● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
        //● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
        //● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
        //无效的bug：open->closed open-rejected-closed.

        // 如何开始第一次测试
        // 1、阅读所有项目有关的文档，包括：需求文档、设计文档、用户手册
        //2、尽可能参加各种项目会议，了解项目的背景、人员组成、尽可能的了解需求和业务。特别针对业务
        //专业性较强的项目，例如银行业务，需要了解各种业务知识，如高低柜、一二三类账户等、存款、贷款等。
        //3、熟悉项目所使用的测试管理工具、配置管理工具，获取对应的地址和登录方式
        //4、阅读已有的测试方案和测试案例
        //5、阅读旧有的bug库，了解系统功能。尤其重要的是和现有的测试团队保持一致的故障定级原则
        //6、了解公司的规范要求，特别是用例编写规范、用例执行规范、bug提交规范、测试工具工具使用规范等.

        // 测试的执行和bug管理
        // 1. 打开待测试的系统
        //2. 打开测试管理工具用例模块，开始执行用例
        //3. 发现bug！进行复现并确认bug的复现步骤
        //4. 记录bug
        //5. 沟通bug
        //6. 验证以前提交的bug
        //7. 确认本次测试完成
        //8. 编写测试报告.

        //如何发现更多的bug？
        //1、软件测试同样存在二八原则，80%的故障集中于20%的模块，如果某部分问题较多，加强测试广度
        //和深度！
        //2、开发人员也存在二八原则，80%的故障集中于20%的开发人员，如果某些开发人员的bug较多，加强
        //他开发模块的测试广度和深度！
        //3、多进行逆向思维和发散性的思维
        //4、不要局限于用例和需求文档
        //5、尽早介入项目, 不要等到开发的差不多了再介入项目

        // 产生争执怎么办？
        //  （处理人际关系，）
        // 1、先检查自身，是否bug描述不清楚
        // 2、站在用户角度考虑问题 应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员
        //更加积极地、高质量地修改Bug。
        // 3、BUG定级要有理有据
        // 4、提高自身的技术和业务水平.
        // 5、开发人员不接受时，不要争吵


        // 测试用例篇
        //  熟悉黑盒测试的用例方法， 等价类划分法，边界值法...
        //  测试用例的设计方法
        //  基于需求的设计方法
        //  等价类
        //  边界值
        //  判定表
        //  正交排列
        //  场景设计法
        //  错误猜测法

        // ***** 测试用例的要素： 测试环境， 测试数据， 预期结果， 操作步骤. *****
        // bug 有他的执行结果， 测试用例里面需不需要这个执行结果？ 不需要， 因为执行结果 是要执行测试用例的时候才能要这个执行结果
        //                                                      但是此时测试用例还没有， 那么哪里来的执行结果
        //        写测试用例是需要消耗时间的：
        //          测试用例的好处是什么？
        //              提高测试效率，节省测试时间
        //              测试用例是自动化测试用例的前提 （自动化： 让代码代替人去完成这个工作）.
        //
        // 测试用例的设计方法：
        // ***** 基于需求去设计一个用例的方法 *****
        //      需求文档->梳理需求（掌握需求）->针对文档设计测试用例（基于需求设计测试用例）
        //  那么拿到一个需求： 如何通过基于需求来设计测试用例？

        // 有这样的一个流程
        //
          /*
                                        -> 界面 (UI 设计搞 如： 页面美观， 页面布局， 页面元素)
                            -> 功能相关的 -> 业务流程相关 (需求规格说明书)
                                        -> 易用性 （符合用户操作， 用户使用起来要流畅）
        基于需设计的测试用例
                                            -> 兼容 （电脑操作系统， 浏览器， 手机， 平板）
                            -> 非功能相关的   ->  性能 （接口响应时间， 接口请求承载量， 吞吐量必须符合期望）
                                            -> 安全  （密码加密展示，密码加密保存，黑客攻击， 防止sql注入）
                                            -> 网络  （4G，3G，wifi， 弱网， 可以用 charles， fiddler 来模仿弱网）.

                */

        // 基于需求去设计测试用例
        // 这就需要用到

        // 参考标准： 需求文档
        // 只是针对需求进行了大概的测试


        // **** 等价类 *****
        // 等价类：
        // 依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果
        // 这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的
        // 功能覆盖，解决了不能穷举测试的问题。

        // 可以划分为 有效等价类 和 无效等价类
        // 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验
        //证程序是否实现了规格说明中所规定的功能和性能
        //        满足用户需求输入集合， 有效等价类
        // 无效等价类：根据需求说明书，不满足需求的集合。
        //        不满足用户需求的输入集合，无效等价类


        // 接下来用这个 等价类 思想设计测试用例步骤
        // 1. 充分理解需求
        // 2. 划分有效等价类， 无效等价类
        // 3. 从有效等价类中抽取其中一个数据进行设计测试用例； 从无效等价类中抽取其中一个进行测试用例设计

        /*
                                                -> 有效等价类   6-15位   （如：10）
        等价类设计一个测试用例 （用户名长度： 6-15位）
                                                -> 无效等价类  小于 6 位，（如：3） 大于 15 位 （如： 19）


        */


        // ***** 边界值 *****
        // 边界点： （重要） 设计测试用例的时候 需要用到这个测试用例
        //   1. 上点： 边界上的点
        //   2. 内点： 边界内的点
        //   3. 离点： 边界值附近的点 （闭区间 在区间外距离上点最近的点， 开区间 区间内距离上点最近的点）.


        // 如： ------------------6---------------15-------------------->
        // 闭区间下：
        //  上点： 6， 15
        //  内点： 如 13 （从区间内部找一个就可以了）
        //  离点： 5， 16  这是一个闭区间的 离点

        // 半开半闭区间 （以左开右闭为例）
        //  上点： 6， 15
        //  内点： 如 13 （从区间内部找一个就可以了）
        //  离点： 7， 16  这是一个闭区间的 离点

        // 这时候就要拿这几个点设计测试用例了

        // 边界值设置测试用例的方法
        // 1 充分理解需求 （这里还是 用户名 6 - 15 位）
        // 2.找边界点  （边界点， 上点， 内点， 离点）
        // 3.针对边界点设计测试用例

        /*
                                                -> 上点   6 和 15
        等价类设计一个测试用例 （用户名长度： 6-15位）  -> 内点    如： 13
                                                -> 离点   5和16

        */


        // ***** 错误猜测法 ******

        // **** 因果图法 *****
        // **** 判定表法 ***** （为什么不写成因果图呢？ 因为我觉得 使用因果图之后 后面还要转换为 判定表法）
        // 判定表是一种以表格形式分析和表达多逻辑条件下执行不同操作的工具。
        //它能够将复杂的问题按照各种可能的情况全部列举出来，因此，利用判定表能够设计出完整的测
        //试用例集合
        // 关系：
        //   与 ： 所有的条件都必须满足 ， 若有一天不满足就判定为假
        //   或 ： 所有的条件满足其中一个就可以， 如果条件全部为假， 全部就为假
        //  恒等 ： 如果条件为真，那么结果必定为真。
        //  非 ： 只有条件为假，结果才为真

        // 这样的思想如何设计测试用例：
        // (1)分析所有可能的输入和可能的输出。
        //(2)找出输入与输出之间的对应关系。
        //(3)设计判定表。
        //(4)把判定表对应到每一个测试用例。

        // 假设业务单据的处理规则为：“淘宝618活动，订单已提交，订单合计金额大于300元或有红包，则进优惠”。
        //  输入 ： 订单已提交， 订单金额， 有红包
        //  输出 ： 优惠， 不优惠
        // 输入和输出之间的关系： 1. 订单已提交， 金额大于300， 有红包， 优惠
        //                    2. 订单已提交， 金额大于300， 没有红包， 优惠
        //                    3.  订单已提交  金额小于300， 有红包， 优惠
        //                    4. 订单已提交  金额小于300， 没有红包， 不优惠
        //                    5. 订单未提交  金额大于300， 没有红包， 不优惠
        //                    6. 订单未提交  金额大于300， 有红包， 不优惠
        //                    7.订单未提交  金额小于300， 没有红包， 不优惠
        //                    8. 订单未提交  金额小于300， 没有红包， 不优惠

        // 接下来画图
        // 判定标配就可以设计成 8 列
        // 5 行
        // 订单提交， 金额大于300， 有红包， 优惠， 不优惠

        // 编写测试用例
        /*
               淘宝 618 活动判定表测试用例 -> （上述八种情况）
         */

        // 那么为什么这样写呢？
        // 命名都已经分析出来， 还要再画出来， 再设计个测试点
        // 因为这是一个测试用例要素， 后期要针对这几个测试点来增添测试用例要素的

        // 测试用例的基本要素
        //


        // ***** 正交表法 *****
        // 什么是正交表
        //
        //  最简单的正交表是L^4(2^3)，含意如下：“L”代表正交表；L下角的数字“4”表示有 4 横行，简称行，即要做四次试验；括号内的指数“3”表示有3 纵列，简称列，
        //  即最多允许安排的因素是3 个；括号内的数“2”表示表的主要部分只有2 种数字，即因素有两种水平1与2。正交表的特点是其安排的试验方法具有均衡搭配特性。
        //
        // 正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。
        //   正交排列法能够使用最小的测试过程集合获得最大的测试覆盖率。
        //   当可能的输入数据或者输入数据的组合数量很大时，由于不可能为每个输入组合都创建测试用例，可以采用这种方法。

        // 名词
        //  因素：此次需求的一个出入， 也叫做一个 变量
        //  水平： 变量的取值
        // 性质
        //   1.每列中各数字出现的次数都一样多。
        //   2.任何两列中的各有序数对出现的次数都一样多。
        // 如何通过正交表设计测试用例
        // 充分理解需求 -> 确定因素水平 -> 画正交表 -> 补充正交表 -> 将正交表转换成测试用例

        // 例子：
        //继续以注册的需求为例：
        //姓名、邮箱、密码、确认密码、验证码必须全部输入，才能进行注册

        // 那么这里面的因素和水平是什么？
        // 因素：姓名、邮箱、密码、确认密码、验证码
        // 水平：填写或者不填写
        // 那么正交表怎么画？
        // 用 allpirs 画正交表

        // allpirs 的使用
        // 先创建一个表格
        // excel 表格， 把因素放在里面
        // 并 把 水平放在里面

        // 然后 复制并保存 到 allpirs 路径下
        // 之后 再用 控制台命令
        // 进入到 allpirs 目录里面
        // 然后执行 allpirs.exe 你保存的文件名字.txt > 你保存的文件名字_result.txt 形式
        // 这丫就保存成功了

        /*

         测试用例：
                        -> 姓名， 密码， 邮箱， 确认密码， 验证码填写
         用户注册（正交表） -> 姓名填写， 密码，邮箱，确认密码，验证码都不填写
                        -> ..... 等情况

         */

        // ***** 场景设计法 *****
        // 现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触
        //发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者
        //设计测试用例，是测试用例更容易理解和执行。
        //典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功
        //能细节忽视业务流程要点的错误倾向

        // 通常情况下需要把用户经常使用的功能模块串联到一起进行测试


        // **** 错误猜测法 *****
        // 面试题
        //    1.如何去模拟弱网： 可以借助许多的工具， Charles 或者 fiddler 等等
        //    2.接口如何测试， 可以借助工具（postman）， 或者代码



        // 测试用例设计万能公式
        // 功能，界面，易用，兼容，性能，安全，网络，中断...

        // 加入有一个物体
        // 功能
        //  加入有一个物体：这个物体主要是用来干什么的
        //  假如是一个软件：功能就是 软件的实现功能（结合生活来）

        // 界面：
        // 如果是物体的话： 外表，材质，大下，容量...方面
        // 如果是一个软件的话： 界面，字体大小，字体颜色，页面布局....

        // 易用： 根据经验（操作简单，使用流畅）， 人性化
        // 兼容： 如果是一个物体： 物体除了本质的功能，还有没有其他功能
        //      软件：操作系统，设备，浏览器版本

        // 性能： 物体 ： 使用寿命
        //      软件： 响应时间， 吞吐量， 并发数
        // 安全： 物体： 物体材质是否有毒， 物体会不会对人体健康造成威胁
        //      软件： sql注入， xss 漏洞， 输入有毒的脚本
        // 网络： 2G，5G，WIFI
        // 中断： 一个电话突然打过来

        // **** 面试题 *****

        // 水杯测试用例

        // 水杯测试用例 （用万能公式）

        // 微信发朋友圈



        // 测试分类
        // ***** 按照测试对象划分 ****

        // 界面测试
        /*
        界面测试（简称UI测试)，指按照界面的需求（一般是UI设计稿）和界面的设计规则，对我们软件界面所
        展示的全部内容进行测试和检查，一般包括如下内容：
            验证界面内容显示的完整性，一致性，准确性，友好性。比如界面内容对屏幕大小的自适应，换
            行，内容是否全部清晰展示；
            验证整个界面布局和排版是否合理，不同板块字体的设计，图片的展示是否符合需求；
            对界面不同控件的测试，比如，对话框，文本框，滚动条，选项按钮等是否可以正常使用，有效和
            无效的状态是否设计合理；
            界面的布局和色调符合当下时事的发展。

         */

        // 可靠性测试
        /*
                可靠性（Availability）即可用性，是指系统正常运行的能力或者程度，一般用正常向用户提供软件服务
                的时间占总时间的百分比表示。
            可靠性 = 正常运行时间/（正常运行时间+非正常运行时间）*100%（比例越高，软件可靠性越高）
                系统非正常运行的时间可能是由于硬件，软件，网络故障或任何其他因素（如断电）造成的，这些因素
                能让系统停止工作，或者连接中断不能被访问，或者性能急剧降低导致不能使用软件现有的服务等。
                可用性指标一般要求达到4个或5个“9”，即99.99%或者99.999%
                不同的应用系统，可用性的要求是不一样的，非实时性的信息系统或一般网站要求都很低，99%和
                99.5%就可以了，但是军事系统，要求则很高；
         */

        // 容错性测试
        /**
         * 容错性测试是指系统能够处理异常，用户的错误操作而不至于系统崩溃，从而能够提高系统的可用性。
         * 容错性测试包含以下方面：
         *      1.输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内
         *      部消化掉，而不会导致系统出错甚至崩溃。
         *      比如数据级测试，校验测试，环境容错性测试，界面容错性测试
         *      2.灾难恢复性测试。
         *        通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据
         *        是否能尽快恢复。
         */

        // 文档相关的测试
        /**
         * 国家有关计算机软件产品开发文件编制指南中共有14 种文件，可分为3 大类。
         * –开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明
         * 书、数据库设计说明书、模块开发卷宗。
         *
         * –用户文件:用户手册、操作手册，用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善
         * 软件可靠性；降低技术支持成本。
         *
         * –管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
         * 在实际的测试中，最常见的是用户文件的测试，例如：手册说明书等。也会有一些公司对需求文档进行
         * 测试，来保证需求文档的质量。
         *
         * 文档测试的关注点：
         * 文档的术语
         * 文档的正确性
         * 文档的完整性
         * 文档的一致性
         * 文档的易用性
         */

        // ** 兼容性测试 **
        /**
         * 兼容性测试需求是指明确要测试的兼容环境，考虑软，硬件的兼容，就软件兼容来说，主要考虑以下几
         * 个方面：
         * 系统自身版本的兼容，用户已有数据的兼容，数据兼容是重中之重，对用户来说，数据是最有价值的。
         * 测试与应用环境的兼容性，比如操作系统，应用平台，浏览器的兼容
         * 测试与第三方系统以及第三方数据的兼容性
         *
         * 对于环境（操作系统，应用平台）兼容性的测试不仅仅局限在操作系统，浏览器这两个因素，还包括以下，32
         * 位，64位CPU；手机平台Android ，iOS，Windows Phone；支持不同的Internet连接速度。
         * 对于iOS和Android两个平台，还要区分手机和平板电脑，考虑不同的型号（屏幕尺寸，分辨率等）。
         */

        // 易用性测试
        //许多产品都应用人体工程学的研究成果，是产品在使用起来更加灵活和，舒适。软件产品也始终关注用
        //户体验，让用户获得舒适，易用的体验，针对软件这方面的测试称之为易用性测试。
        //易用性在ISO25020标准中指容易发现，容易学习和容易使用。易用性包含七个要素：符合标准和规
        //范，直观性，一致性，灵活性，舒适性，正确性和实用性。我们主要讨论以下几个方面
        //1，标准性和规范性
        //对于现有的软件运行平台，通常其UI标准已经不知不觉地被确立了，成为大家的共识。多数用户已经习
        //惯并且接受了这些标准和规范，或者说已经认同了这些信息所代表的的含义。比如安装软件的界面的外
        //观，在什么场合使用恰当的对话框等。
        //所以用户界面上的各中信息应该符合规范和习惯，否则用户使用起来会不舒适，并得不到用户的认可。
        //测试人员需要把与标准规范，习惯不一致的问题报告为缺陷
        //2，直观性
        //用户界面的直观性，要求软件功能特性易懂，清晰。用户界面布局合理，对操作的响应在用户的预期之
        //中。比如数据统计结果用报表的形式（条形图，扇形图等）展示清晰直观；现在主流的很多搜索引擎和
        //日历的设计也有直观性的特点；
        //3，灵活性
        //软件可以有不同的选项以满足不同使用习惯的用户来完成相同的功能。但是灵活性的设计要把握好度，
        //不然可能由于太多的用户状态和方式的选择，增加了软件设计的复杂性，和程序实现的难度。
        //例如手机键盘有九宫格和全键盘，还支持手写，满足了不同用户的需求
        //4，舒适性
        //舒适性主要强调界面友好，美观，操作过程顺畅，色彩用运恰当，按钮的立体感等。例如左手鼠标的设
        //置给习惯用左手的人带来了便利，也为右手十分劳累时提供了另一种途径；

        // 应用性测试

        // 安装卸载测试
        /**
         *
         * 应用的安装和卸载在任何一款APP中都属于最基本功能。一旦出错，就属于优先级为紧要Critical的缺
         * 陷。主要需要考虑以下方面：
         *      软件不同的安装和卸载方式；
         *      应用是否可以在不同的环系统，版本下安装（安装兼容性）
         *      安装或者卸载过程中是否可以手动暂停，或者取消
         *      安装空不足的时候系统是否有提示
         *      是否可以正常的卸载，以及应用软件的各种卸载方式
         *      卸载和安装过程中出现环境问题，软件是否可以正常并且合理的应对，比如死机，断电，断网等
         */

        // 安全测试
        /**
         * 安全性是指信息安全，是指计算机系统或网络保护用户数据隐私，完整，保护数据正常传输和抵御黑
         * 客，病毒攻击的能力。安全性测试属于非功能性测试很重要的一个方面，系统常见的安全漏洞和威胁如
         * 下
         *   输入域，如输入恶性或者带有病毒的脚本或长字符串；
         *   代码中的安全性问题，如SQL/XML注入
         *   不安全的数据存储或者传递
         *   数据文件，邮件文件，系统配置文件等里面有危害系统的信息或者数据；
         *   有问题的访问控制，权限分配等
         *   假冒ID：身份欺骗
         *   篡改，对数据的恶意修改，破坏数据的完整性
         *  安全性测试的方法有代码评审，渗透测试，安全运维等，常用的静态安全测试工具有，Coverity，IBM
         * Appscan Source，HPFortify，常用的动态安全测试有OWASP的ZAP，HP WebInspect等。其中静态安
         * 全测试是常用的安全性测试的方法。
         */

        // 性能测试
        /**
         * 我们在使用软件的时候有时会碰到软件网页打开时越来越慢，查询数据时很长时间才显示列表，软件运
         * 行越来越慢等问题，这些问题都是系统的性能问题引起的。
         * 要进行软件产品的性能问题，要对产品的性能需求进行分析，然后基于系统的性能需求和系统架构，完
         * 成性能测试的设计和执行，最后要进行持续的性能调优。常见的性能问题如下：
         * 资源泄露
         * 资源瓶颈
         * 线程死锁，线程阻塞
         * 查询速度慢或效率低
         * 受外部系统影响越来越大
         * 衡量一个系统性能好坏的关键性指标有，用户响时间，事务平均响应时间（TPS），吞吐率，每秒点击
         * 次数，内存和CPU使用率等。
         */

        // 内存泄露测试
        /**
         * 造成内存泄露的原因有很多，最常见的有以下几种。
         *      分配完内存之后忘了回收。
         *      程序写法有问题，造成没办法回收（如死循环造成无法执行到回收步骤）。
         *      某些API函数的使用不正确，造成内存泄露。
         *  内存泄漏的检测方法
         *      人工静态法：代码走读，人工查找未被回收的内存。
         *      自动工具法：借助相应测试内存泄漏的工具，如Visual Leak Detector，记录每次内存分配，清楚
         *      告诉用户内存是如何泄漏的。
         */

        // **** 按照是否查看代码划分 *****
        // ** 黑盒测试 **
        /**
         * 黑盒测试就是在完全不考虑程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规
         * 定正常使用、是否能适当的接收输入数据而输出正确的结果，满足规范需求。  （黑盒测试用例设计方法）
         * 所以，黑盒测试又称之为数据驱动测试，只注重软件的功能
         * 黑盒测试的优点
         *      不需要了解程序内部的代码以及实现，不关注软件内部的实现。
         *      从用户角度出发设计测试用例，很容易的知道用户会用到哪些功能，会遇到哪些问题，锻炼测试人员的产品思维
         *      测试用例是基于软件需求开发文档，不容易遗漏软件需求文档中需要测试的功能。
         * 黑盒测试的缺点是不可能覆盖所有代码。（导致了黑盒测试代码覆盖率较低）
         */
        // ** 白盒测试 **
        /**
         * 白盒测试又称为结构测试或逻辑测试，它一般用来分析程序的内部结构，针对程序的逻辑结构来设计测
         * 试用例进行测试。
         * 白盒测试的测试目的是，通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不
         * 同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。
         * 主要包含六种测试方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。
         */
        // 白盒测试。
        //  优点：代码覆盖率比较高
        //  缺点： 业务功能覆盖较低

        // 灰盒测试 （多数用到集成方面）
        /**
         *灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输
         * 出、输入的正确性，同时也关注程序内部的情况。
         */

        // **** 按照开发阶段测试 ****
        // ** 单元测试 **
        //单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设
        //计的最小单位：模块。又称为模块测试
        //测试阶段：编码后或者编码前（TDD）
        //测试对象：最小模块（在Java中是一个一个类方法，C语言中函数）
        //测试人员：白盒测试工程师或开发工程师
        //测试依据：代码和注释+详细设计文档
        //测试方法：白盒测试 （上面六种方法）
        //测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试

        //** 集成测试(Integration Testing) **
        // 集成测试也称联合测试（联调）、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口
        //及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。
        //测试阶段：一般单元测试之后进行 *
        //测试对象：模块间的接口
        //测试人员：白盒测试工程师或开发工程师
        //测试依据：单元测试的模块+概要设计文档
        //测试方法：黑盒测试与白盒测试相结合
        //测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块
        //缺陷对系统的影响

        // **系统测试(System Testing)**
        /**
         * 将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。
         * 测试阶段：集成测试通过之后
         * 测试对象：整个系统（软、硬件）
         * 测试人员：黑盒测试工程师
         * 测试依据：需求规格说明文档
         * 测试方法：黑盒测试
         * 测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等
         */

        //**回归测试(Regression Testing)**
        //回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
        //在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。随着系统
        //的庞大，回归测试的成本越来越大，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很
        //有意义的。

        // **冒烟测试（smoke testing）（系统测试之前完成）**
        // 需求讲解 -> 梳理测试点（设计测试用例）（这里面就包含了冒烟测试，只要测试点属于本次测试的主流程， 那就可以成为测试用例）
        // -> 评审测试用例（确定了所有的测试用例（包含了冒烟测试用例）） ->  测试（先去执行冒烟测试用例， 如果测试通过，此时进入正式测试，如果不通过，那就停止测试）
        //  -> 项目上线

        //冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件主要功能和核心流程正
        //常，在正式进行系统测试之前执行。冒烟测试一般在开发人员开发完毕后提交给测试人员来进行测试
        //时，先进行冒烟测试，保证基本功能正常，不阻碍后续的测试。
        //如果冒烟测试通过，则测试人员开始进行正式的系统测试，如果不通过，则测试人员可以让开发人员重
        //新修复代码直到冒烟测试通过，再开始进行系统测试。
        //回归测试和冒烟测试都属于系统测试。

        // 验收测试 （这是产品上线之前最后一个测试流程）
        // 验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。验收
        //测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展
        //示该软件系统满足原始需求。
        //测试阶段：系统测试通过之后
        //测试对象：整个系统（包括软硬件）。
        //测试人员：主要是最终用户或者需求方。
        //测试依据：用户需求、验收标准 （验收标准是 测试人员写的）
        //测试方法：黑盒测试
        //测试内容：同系统测试(功能...各类文档等)

        //***** 按照实施组织划分 *****
        //  *** 阿尔法测试 ***
        // α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的
        //测试。α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。
        //大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试。α测试不能由程序员或测试员完成。

        // ** β测试 **
        // Beta测试是一种验收测试。Beta测试由软件的最终用户们在一个或多个场所进行。
        //α测试与Beta测试的区别：
        //测试的场所不同：Alpha测试是指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场
        //所进行的测试。
        //Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。beta测试的环境是不受开发
        //方控制的,用户数量相对比较多,时间不集中。
        //alpha测试先于beta测试执行。通用的软件产品需要较大规模的beta测试,测试周期比较长。
        // ----> 两者之间的区别
        // 环境区别： α测试是在公司内部进行测试，β测试环境是不确定的
        // 测试人员类型： α测试是公司内部人员，β测试测试人员是用户
        // 测试人员数量： α测试测试人员数量较少，β测试测试人员较多
        // 阶段： α测试是在β测试之前测试的
        // 测试周期： α测试周期较短，β测试周期较长

        //

        // ****** 按照是否运行代码划分（了解） ****
        // ***** 按照是否手工划分 ******
        // 手工测试
        // 手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须
        //的一个步骤。总结优缺点：
        //  优点：自动化无法替代探索性测试、发散思维结果的测试。
        //  缺点：执行效率慢，量大易错。

        // *** 自动化测试 ***
        // 就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。简单说
        //自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。
        //自动化测试比如功能测试自动化、性能测试自动化、安全测试自动化。
        //自动化测试按照测试对象来分，还可以分为接口测试、UI测试等。接口测试的ROI（产出投入比）要比
        //UI测试高。

        // 自动化实施步骤：
        //1.完成功能测试，版本基本稳定
        //2.根据项目特性，选择适合项目的自动化工具，并搭建环境
        //3.提取手工测试的测试用例转化为自动化测试的用例
        //4.通过工具、代码实现自动化的构造输入，自动检测输出结果是否符合预期
        //5.生成自动测试报告
        //6.持续改进，脚本优化。

        // ***** 按照地域划分（了解） ****
        // 国际化测试
        // 本地化测试
    }
}
